## Summary

### Why?

The Stovepipe gateway minted a SPID and published to the queue but persisted nothing, so a freshly ingested commit had no observable record until the orchestrator processed it. SubmitQueue's gateway records an `accepted` status synchronously on entry and owns the request log end to end; this brings the Stovepipe gateway to the same shape now that the entity stores exist.

### What?

Wires the gateway to the gateway-owned `RequestLogStore` (persist + consume); identity stays the synthetic SPID and there is no new read RPC or proto change.

- `Ingest` now records an `accepted` `RequestLog` synchronously (written straight to storage, before publishing to the start topic) so the status is visible the moment the RPC returns. A log-write failure aborts before anything is published.
- Adds a gateway `log`-topic consumer (`stovepipe/gateway/controller/log`) that persists `RequestLog` entries — the gateway is the sole writer of the request log; the orchestrator only publishes log events for it to persist.
- Adds the `log` topic key to `stovepipe/core/topickey`.
- Rewires the example gateway server: opens the app DB (storage + SPID counter) and the queue, builds a registry that publishes `start` and consumes `log`, registers `Ingest` behind an InvalidArgument interceptor, and runs the log consumer with graceful shutdown.
- Adds `local-init-stovepipe-schemas` (storage + counter to mysql-app, queue to mysql-queue) and points the gateway / full-stack local start targets at it.

The `IngestController` and the log consumer both depend on the narrow `RequestLogStore` interface rather than the full `Storage` facade, since that is all either needs.

## Test Plan

- `bazel test //stovepipe/...` — all targets pass (new gateway log consumer + updated ingest tests)
- `bazel build //stovepipe/... //example/stovepipe/...`
- `make fmt`, `make lint-license`, `make gazelle` — clean / idempotent